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1 . A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible 
for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) has 
been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 
CFR 1.114. Applicant's submission filed on 2/22/2006 has been entered. 

2. Claims 1-24 are pending in this application. Claim 7 is cancelled. Claims 1-6 and 8-24 
are presented for examination. 

3. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

4. Claims 1-6 and 8-24 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

A. The following words or phrases are not clearly understood, rendering corresponding 
claims vague or indefinite: 

a) "information indicating a folder", "information indicating the folder", claim 1, 
lines 7-8, 14, claim 2, line 3-4, claim 5, line 2, claim 9, line 3, claim 15, lines 7-8, 17-18, 
it is unclear what "information indicating" means, is it information pointing to the location 
of a folder, information about the name of a folder, size of a folder, data units in a folder, 
etc. 
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b) "information indicating the folder is placed in the message in an element or 
field". Claim 1, line 14-16, claim 15, lines 17-19. Differentiation between an element in 
the message and a field in the message is unclear within the context of a message in the 
claim. An element of the message or a field of the message may mean the same thing or 
an element may be part of a field. Moreover, the use of "or" emphasizes that there is no 
functional difference between the two names if they mean different locations. 

c) "information indicating the folder is placed in the message in an element or 
field different from". The use of "or" stresses the fact that "data" which is placed in a 
different location, may be also placed in any of an element or a field in the message. 

Examiner concludes with the interpretation that what is being basically claimed is 
that data and information indicating the folder are being placed separately in the 
message (as indicated by applicant remarks of 1/19/2006). Claims 2 and 3 do not add to 
the clarification of the above, as long as the relation between a field in the message and 
an element in the message is not clear. 

d) "the protocol command element in combination with the data identification 
element indicates the folder", claim 8, lines 3-5. First, it is unclear what "indicates" 
means, again, is it a pointer to a folder, a name of a folder, size of a folder, data units in 
a folder, etc. Second, it is unclear what "protocol command element in combination with 
the data identification element indicates the folder" means. 

5. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or 
described as set forth in section 102 of this title, if the differences between the subject 
matter sought to be patented and the prior art are such that the subject matter as a 
whole would have been obvious at the time the invention was made to a person having 
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ordinary skill in the art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 

6. Claims 1-6 and 8-24 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Applicant Admitted prior Art, hereinafter "AAPA", in reference to SyncML Initiative (including 
standards and specifications for SyncML, SyncML Representation protocol, and SyncML Sync 
Protocol, SyncML Device Management Protocol) 

7. As to claim 1, AAPA discloses the invention substantially as claimed including a method 
for at least partially synchronizing a first data store residing on a first device and a second data 
store residing on a second device (spec, p1, lines 17-24), the data stores each being used for 
storing data as data units in folders (folder is any container of data unit, spec, p5, lines 28-31), 
the method comprising the first device preparing a message including information indicating a 
folder of the first data store, and sending the message to the second device (spec, p5, line 32 
to p6, lines 2- 24, spec, p6, lines 12-18, and p9, lines 21-24); wherein said information 
indicating the folder of the first data store is placed in the message in an element or field 
different from where data of the first data store is placed or would be placed if included in the 
message (part of the standard, SyncML Representation Protocol). 

8. As to claim 15, the claim is rejected for the same reasons as claim 1 above. In addition, 
AAPA discloses a device adapted for at least partially synchronizing a first data store residing 
on the device with a second data store residing on a second device ( spec, p1, lines 17-24), the 
data stores each being used for storing data as data units in folders (folder is any container of 
data unit, spec, p5, lines 28-31), the device comprising: means for preparing a message 
including information indicating a folder of the first data store, and sending a message to the 
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second device (spec, p5, line 32 to p6, lines 2- 24, spec, p6, lines 12-18, and p9, lines 21-24); 
wherein said information indicating the folder of the first data store is placed in the message in 
an element or field different from where data of the first data store is placed or would be placed 
if included in the message (part of the standard, SyncML Representation Protocol). 

9. As to claim 2, AAPA discloses the element or field where the information indicating the 
folder is placed in a field of the message (part of the standard, SyncML Representation 
Protocol). 

10. As to claim 3, AAPA discloses data of the first data store is placed or would be placed in 
a data element of the message (spec, p7, lines 18-25; and p8, line 30 to p9, line 7, it is obvious 
that a data, if it would be place, would be place in a data element). 

11. As to claim 4, AAPA discloses the data element is a data element of a protocol 
command element (spec, p7, lines 18-25; and p9, lines 12-17). 

12. As to claims 5 and 6, AAPA discloses the information indicating the folder is included in 

a non-data element of the message, and wherein the non-data element is a non-data element of 
a protocol command element (spec, p9, lines 12-17; also it is obvious within the SyncML 
Representation Protocol that data about data "meta-data" would be place in a non-data 
element). 

13. As to claim 8, AAPA discloses a data identification element is contained in a protocol 
command element in the message, and the protocol command element in combination with the 
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data identification element indicates the folder of the first data store (spec, p7, lines 8-14; and 
p9, lines 8-11; also it is obvious within the SyncML Representation Protocol that the SyncML 
message contains the SynchML command, as well as the related data and meta-information). 

14. As to claim 9, AAPA discloses a data identification element is included in the message 
and the information indicating the folder of the first data store is provided in the data 
identification element (spec, p6, lines 2-24; p7, lines 8-14; and p9, lines 21-24; also it is obvious 
within the SyncML Representation Protocol that the SyncML message contains the SynchML 
command, as well as the related data and meta-information). 

15. As to claim 10, AAPA discloses the first device functions as a client in a client-server 
protocol and the second device as a server in the client-server protocol (spec, p1 , line 17 to p2, 
line 9). 

1 6. As to claim 1 1 , AAPA discloses the first device functions as a server client-server 
protocol and the second device as a client in the client-server protocol, and the step of the first 
device preparing the message is responsive to a client message from the second device and 
includes resolving any conflicts posed by the client message in respect to the first data store 
(spec, p1, line 17 to p2, line 9). 

17. As to claims 12 and 20, AAPA discloses the data in the data stores are used for device 
management by applications hosted on the devices (spec, p2, lines 30-33; and SyncML device 
management protocol). 
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18. As to claim 1 3 and 21 , AAPA discloses the data in the data stores are used as user 
data by applications hosted on the devices (spec, p1 , line 31 to p2, line 9). 

19. As to claim 14, a computer program product comprising a computer readable storage 
structure embodying computer program code thereon for execution by a computer processor, 
with said computer program code characterized in that includes instructions for performing the 
steps of the method of claim 1 is inherent in AAPA's disclosure and the corresponding sync 
SyncML protocol. 

20. As to claim 16, AAPA discloses the device is either a wireless communication terminal 
or a wire line communication terminal (spec, p1, lines 17-24). 

21 . As to claim 1 7, AAPA discloses the device functions as a client in a client-server model 
(spec, p1, lines 17-30). 

22. As to claim 18, AAPA discloses the device functions as a server in a client-server 
model, and further comprises means for receiving a request to synchronize from the second 
device, and for then sending the message in response to the request to synchronize (part of 
sync SyncML protocol). 

23. As claim 19, AAPA discloses means for receiving the message, and wherein the device 
functions as a server in a client-server model and include means for resolving conflicts posed by 
the message (spec, pi, line 17 to p2, line 9). 
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24. As to claim 22, AAPA discloses a system, comprising a first device according to claim15 
And also comprising the second device hosting the second data store (spec, p1, line 17 to p2, 
line 9). 

25. As to claim 23, AAPA discloses the first device functions as a server in a client-server 
model and the second device functions as a client in the client-server "model (spec, p1 , line 17 
to p2, line 9). 

26. As to claim 24, AAPA discloses the means for sending to the second device a message 
is responsive to request sent by the second device to synchronize to the second device (Part of 
Sync SyncML protocol). 

27. AAPA may not explicitly disclose and in details the field components of the message 
between the first and the second devices, however, it would have been obvious to one skilled in 
the art at the time of the invention that applicant's disclosure does not vary from the SyncML 
Initiative (including standards and specifications for SyncML, SyncML Representation protocol, 
and SyncML Sync Protocol, SyncML Device Management Protocol). The SyncML Message is 
an individual XML document consisting of one or more elements each of one or more element 
types. The document consists of a header, specified by the SyncHdr element type, and a body, 
specified by the SyncBody element type. The SyncML header specifies routing and versioning 
information about the SyncML Message. The SyncML body is a container for one or more 
SyncML Commands. The SyncML Commands are specified by individual element types. The 
SyncML Commands act as containers for other element types that describe the specifics of the 
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SyncML command, including any data or meta-information. It is obvious that the data and meta- 
information are placed in different location in the message. 

28. Applicant discloses in p9, lines 21-24 that communicating changes in a directory 
structure is not problematic if the same application takes care of handling the data and handling 
the communication according to a synchronization protocol. At least it is obvious that applicant 
did not clearly point out the patentable novelty, which he or she thinks the claims present in view 
of the state of the art disclosed by the references cited, or the objections made. 

29. Applicant's arguments filed 1/19/2006 have been fully considered but they are not 
persuasive. Therefore rejection of claims 1- 6 and 8-24 is maintained. 

30. In the remarks, applicants argued in substance that (1), none of the prior art, namely 
AAPA, teaches a first device sending a message to a second device with information indicating 
a folder placed in the message in an element or field different from where data of the first data 
store is placed or would be place if included in the message, (2) the application explains that the 
prior art does not provide for communicating changes in the data structure/folders used to 
contain data, (3) SyncML Representation protocol Standard does not teach that information 
about data and information about a change in a data structure are placed in different elements 
or fields. 



31 . Examiner respectfully traverses applicants' remarks. 
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32. Examiner asserts that the prior art as indicated in the specification (page 5, line 32 to 
page 6, line 6) allows for " a user of an application can make changes to both the data units 
that belong to the application (such as adding a new data unit or replacing a data unit with an 
updated version because the user has used the application to change the contents of the data 
unit, and so on) as well as to how the data items are stored (such as adding a new folder and 
moving some data units from an already existing folder to the new folder), i.e. to both the data 
units as well as to the folders (i.e. the overall directory structure)". The prior art also as indicated 
in the specification (page 9, lines 21-24) allows for "communicating changes in a directory 
structure if the same application takes care of handling the data and handling the 
communication according to a synchronization protocol". 

33. Examiner asserts that the specification (page 9, lines 21-24) indicates that 
"communicating changes in a data structure", i.e. information indicating a folder, is not 
problematic in view of the prior art. While this is not a statement that the limitation is taught or 
suggested by the prior art, it is clear indication that it would have been obvious to one skilled in 
the art at the time of the invention to use or modify such prior art in an obvious way in order to 
communicate changes in a data structure, specifically, when the application communicating the 
change is the same as the application that creates or maintains the data contained in the 
folders. 

34. The prior art as indicated in the specification (page 5, line 32 to page 6, line 6) allows for 
"a user of an application can make changes to both the data units that belong to the application 
(such as adding a new data unit or replacing a data unit with an updated version because the 
user has used the application to change the contents of the data unit, and so on) as well as to 
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how the data items are stored (such as adding a new folder and moving some data units from 
an already existing folder to the new folder), i.e. to both the data units as well as to the folders 
(i.e. the overall directory structure)". In other words, the prior art does provide for 
communicating changes in the data structure/folders used to contain data. 

35. The specification (page 6, line 12 to page 9, line 20) gives a brief about SyncML 
Representation Protocol Standard, and which asserts that different information are placed in 
different elements or fields. It is noted that ""SyncML message is a nested structure consisting 
of one or more elements types, and one or more SyncML messages can be associated with 
what is called a SyncML package. The SyncML Message is an individual XML document 
consisting of one or more elements each of one or more element types. The document consists 
of a header, specified by the SyncHdr element type, and a body, specified by the SyncBody 
element type. The SyncML header specifies routing and versioning information about the 
SyncML Message. The SyncML body is a container for one or more SyncML Commands. The 
SyncML Commands are specified by individual element types. The SyncML Commands act as 
containers for other element types that describe the specifics of the SyncML command, 
including any data or meta-information. SyncML defines request commands and response 
commands. Request commands include, for example: add (a command that allows the 
originator to ask that one or more data units be added to data accessible to the recipient) alert 
(allowing the originator to notify the recipient of a condition; copy (allowing the originator to ask 
that one or more data units accessible to the recipient be copied); delete (allowing the originator 
to ask that one or more data units accessible to the recipient be deleted or archived); get 
(allowing the originator to ask for one or more data units from the recipient); and search 
(allowing the originator to ask that the supplied query be executed against one or more data 
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units accessible to the recipient). The only response commands are currently: status (indicating 
the completion status of an operation or that ah error occurred while processing a previous 
request); and results (used to return the data results of either a Get or Search SyncML 
Command). SyncML uses identifiers to identify data units or folders. The identifiers are included 
in what are called the Source and Target element types, and can be a combination of Uniform 
Resource Identifiers (URIs), Uniform Resource Names (URNs), and textual names. As already 
mentioned, the SyncML representation protocol (i.e. a SyncML message) is a document mark- 
up consisting of XML element types. The element types are defined in terms of their purpose or 
usage, parent elements, any restrictions on content or use and content model. The element 
types include so-called common use elements, message container elements, data description 
elements, protocol management elements, and protocol command elements. Common use 
element types are element types used by other SyncML element types, and include, for 
example, archive, for indicating that the data specified in a delete command should be archived 
by the recipient of the delete command, rather than simply deleted. Thus the delete command 
can use the archive common use element and so is referred to as the parent element of the 
archive common use element type, this context. Another common use element type is the Cmd 
element type, which is used to specify the SyncML command referenced by a Status element 
type (and so the Status element type is the parent element in this context). Another is the 
CmdID element type, which is used to specify a SyncML message-unique command identifier, 
and can have various parent elements, including: Add, Alert, Atomic, Copy, Delete, Exec, Get, 

Map, Put, Replace, Results, Search, Sequence, Status, and Sync. Of particular note in respect 

> 

to the invention are the common element types LocName, LocURI, Source, and Target. 
LocName used to specify the display name for the target or source address, and so can have as 
parent elements Target or Source. LOCURI specifies the target or source specific address, and 
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can also have as parent elements Target or Source. The common element type Source is used 
to specify source routing or mapping information; its parent elements include: Item, Map, 
Mapltem, Search, Sync, and SyncHdr. Target is used specify target routing or mapping 
information, and its Parent Elements include: Item, Map, Mapltem, Search, Sync, and SyncHd. 
Message container element types provide basic container support for SyncML messages. Three 
such element types are: SyncML, for specifying the container for a SyncML message, and 
having no parents since it is what is called a root or document element; SyncHdr, for specifying 
the container for the revisioning information or the routing information both) in the SyncML 
message, and having as a parent element SyncML element; and SyncBody, for specifying the 
container for the body or contents of a SyncML message, and also having as a parent element 
a SyncML element. Data description elements are used as container elements for data 
exchanged in a SyncML Message; data description elements include the following element 
types: Data, for specifying discrete SyncML data, and used by (parent elements) Alert, Cred, 
Item, Status, and Search element types; Item, for specifying a container for item data, and used 
by (parent elements) Add, Alert, Copy, Delete, Exec, Get, Put, Replace, Results, and Status; 
and Meta, for specifying meta-information about the parent element type, and used by (parent 
elements) Add, Atomic, Chal, Copy, Cred, Delete, Item, Map, Put, Replace, Results, Search, 
Sequence, and Sync. The protocol management elements include, at present, only the element 
type Status, for specifying the request status code for an indicated SyncML command, and used 
by (parent element) SyncBody. Finally, there are the Protocol Command Elements. These 
include the command elements already mentioned, for example: Add, for specifying that data be 
added to a data collection, used by (parent elements) Atomic, Sequence, Sync, SyncBody; 
Delete; Replace; and so on. The above element types are set out in the standard, SyncML 
Representation Protocol, available on the Internet." 
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36. From the above discussion it is again obvious that applicant did not clearly point out the 
patentable novelty, which he or she thinks the claims present in view of the state of the art 
disclosed by the references cited, or the objections made. 

37. Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Nabil M. El-Hady whose telephone number is (571) 272-3963. The 
examiner can normally be reached on 9:00 - 4:00. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Bunjob Jaroenchonwanit can be reached on (571) 272-3913. The fax phone 
number for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private 
PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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